1. Technical Field
The invention relates to an improved client server model, in particular a computer system comprising a server module and a client module.
2. Related Art
The client-server model of computing is used throughout the computing industry for accessing shared server side capabilities such as print queues, network devices and directories.
To date the client-server model has been primarily used within intranets and extranets in particular in between parties that are well known to each other and have a high degree of trust in one another. Part of this trust relies on the client refraining from the service through overusing finite server side capabilities. As the model is taken up further in more open programming environments in the Internet for instance it becomes even more crucial to protect server based computing resources through intelligently applied measures.
The overuse of these capabilities can comprise simple congestion difficulties but can extend to malicious causes such as denial of service attacks. Existing solutions include over provision of front end servers and/or forced disconnection of overuse clients. However this approach is very costly both in hardware and software resources and provides only abrupt reduction in incoming traffic. Agreements with users can be enforced but often only after the event and through the courts. Alternatively, certain server systems enable the service to notify the clients of service outages or congestion. However this is once again reactive and relies firstly on client recognition and secondly client reaction, neither of which can be guaranteed.
One known example of a client server system is shown in FIG. 1. FIG. 1 shows a system including an ideal client 10 and real client 30 communicating with a server 12. An application 14 makes a method call to services 16 running on the server 12 through a distributed computing stub 18. The stub 18 is used to make the service 16 appear local to the application 14. Calls including to methods, functions and parameters are passed into the stub 18 and are marshalled and then serialized such that they may be conveyed to the server 12 using a client protocol stack 20. At the server end this data is pulled off the wire by the server protocol stack 22 and is then de-serialized and unmarshalled back via a distributed computing skeleton 26 into a method or function call that is passed to the service 16. The service 16 will perform actions and may call upon other services running operating backend systems 24. Return values from the service 16 are similarly processed and sent back to the calling stub 18 and then on to the application 14. In, for example, a Java RMI-based distributed computing system the client application accesses a service capability stub by doing a “lookup” to download the service capability stub to the client system. The stub provides all the marshalling and un-marshalling capabilities to communicate method calls to the server capability. The client application 14 then calls a given method on the stub 18, this method is then marshalled into a message that is transmitted to the server 12 which un-marshals the message back into the method call which is applied to the server capability object. This object performs tasks and then returns a value through the stub back to the calling client application 14.
A problem with this design is that when applications operate normally or obey a Service Level Agreement (SLA), then the calls from a single client or in a more realistic situation multiple clients 30 will not exceed the capability of the server 12. In most enterprises the problem is managed by careful construction and deployment of client applications 12 combined with over-provisioned server capacity. Although clustering and the use of special clustering stubs can distribute the load over multiple servers, it does not overcome the basic problem of client demand outstripping server capacity. When demand does outstrip capacity the server may become impossibly slow, gives rise to failed transactions and dropped connections and eventually the service and server may die completely. In most cases it will be the peak traffic demand that will knock out the server rather than the average traffic.